[レポート] DEV303 – Instrumenting Kubernetes for Observability Using AWS X-Ray and Amazon CloudWatch #reinvent

概要

https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=23149

In this hands-on workshop, we walk you through instrumenting container workloads running on the Amazon Elastic Container Service for Kubernetes (Amazon EKS). Learn how Amazon CloudWatch and the new AWS X-Ray capabilities enable you to quickly understand problem areas in your application and determine customer impact. To participate in this workshop, bring your laptop and have a nonproduction AWS account.

EKS上でContainerを動作させる環境を構築し、Cloudwatch LogsとX-Rayを使うことでアプリケーション障害を監視、検知し、顧客への影響を定義できる。これをワークショップで経験します。

ワークショップ序盤

Moddern ApplicationのトレンドからContainer, Monitoring, Microserviceの概要についての解説。今まで知っている内容が主でしたが改めて復習をする良い機会になりました。

Moddern Application

ここ最近のアプリケーションのトレンドはContainer, ServerlessとMicroservice, Distributed systemというワードに集約されます。これらはモジュールの独立性を保ち、自動化、Continues delivery、障害の分離を実現するために必要不可欠です。

Microserviceの概念は次の言葉で構成されます。Data store, application / logic, Public APIの3つ。

複雑な分散システムの開発、数十を超えるサービス郡の管理、多くのアプリケーション設定、モニタリング及びシステム健常性のためのオペレーション、セキュリティ、システムの進化、これらはMicroserviceにおける課題になっています。

Kubernetes

まずはContainerの実行環境から。今回はKubernetesを利用します。KubernetesはContainer Orchestrationツールの一つです。大きな特徴として

• Opensourceである
• Container, Microservice platform
• Hybrid, Portable
  • 一つの環境にロックアウトするのではなく、環境の選択ができる
  • 環境移行が容易

があります。AWSではKubernetesを利用するためにAmazon Elastic Container Service for Kubernetes(EKS)が用意されています。

Amazon Elastic Container Service for Kubernetes

AWSが提供しているElastic Container ServiceでKubernetesを利用するためのサービスです。これはAWSのサービスの一つではありますが

• AWSの利用を強要するものではない（AWSにロックアウトするわけではない
  • コマンドは途中から kubectl を利用するため、構築ぐらいまでしかコマンドの差分がなさそう
• ただ、他のAWSのサービスとシームレスに繋ぐことができる

上記のような特徴を持っています。Migrationの容易さを極力壊さないための配慮でしょうか。今回のハンズオンはKubernetesの実行環境の中でもEKSを利用します。

Amazon CloudWatch

モニタリングでは様々なメトリクスを監視しできるだけ多くの情報をすばやく集約する基盤環境が必要になります。今回のハンズオンはCloudWatchに情報を集約させます。CloudWatchの機能は、Metricsを監視し条件をトリガーにLambdaを利用したAuto Notificationの仕組みなどを紹介。おなじみなので改めて説明する必要もないかと思うので割愛します。

AWS X-Ray

AWS X-Ray は分散システムのTracingを行うサービスです。AWS Credentialsさえあれば基本的にどこでも動作し、Microserviceで構成されたシステムによって分離してしまうRequestとResponseをグループにまとめて管理・閲覧することができます。

ワークショップ内容

簡単なEコマースサービスを例にEKSでのアプリケーション構築やCloudWatchでの監視設計、そしてX-Rayでの分散環境のRequest, Responseログ集約の設定を行い、実際にログを確認するところまでを自分でやってみるという内容です。割と本格的にMicroserviceが構成されているようで、構成図を確認するとそれぞれ Cart, Catalog, Order, Frontend, Recommendation といった一通り必要なサービスはすべて準備されているようです。

利用した資料のGithub Repositoryはこちら

Lab1

Lab1はPrepareを含めてEKSのCluster作成の実習です。このワークショップでは AWSアカウントはNon-Productionなアカウントを自前で用意する という注意書きがあったのですがこのセクションでなぜかがよく分かりました（後述）

Prepare

Prepareセクションでは開発環境とDocker ImageをPushするためのRepositoryを準備します。折角なのでECRを利用します。ドキュメントはすべてRegionは us-west-2 で指定されているのでこちらですべての環境を構築します。

開発環境はドキュメントを見る限り、Cloud9が推奨されていたのでこちらを利用しました（実際はローカル環境からのほうがすんなり行った模様）

自前のAWSアカウントですので、Switch Roleが必要な場合は適宜 --profile PROFILE_NAME を付ける必要があります。

Oregonにfrontend ECR Repositoryを作成

Cloud9のTerminal環境から docker login できることを確認しました。

EKS

準備が整ったらEKSのCluster作成を実行します。Clusterの作成にはeksctl を利用します。

AWS CLIシリーズではなさそうなので微妙にOptionの指定の方法などがいつもと異なるようですが、そこまで奇妙な違いはなさそうです。ドキュメント指定のコマンドを実行しました。

$ eksctl create cluster \
> --name dev303-workshop \
> --region us-west-2 \
> --nodes=4
2018-11-26T20:22:34Z [ℹ]  using region us-west-2
2018-11-26T20:22:34Z [ℹ]  setting availability zones to [us-west-2b us-west-2c us-west-2a]
2018-11-26T20:22:34Z [ℹ]  subnets for us-west-2b - public:192.168.0.0/19 private:192.168.96.0/19
2018-11-26T20:22:34Z [ℹ]  subnets for us-west-2c - public:192.168.32.0/19 private:192.168.128.0/19
2018-11-26T20:22:34Z [ℹ]  subnets for us-west-2a - public:192.168.64.0/19 private:192.168.160.0/19
2018-11-26T20:22:34Z [ℹ]  using "ami-0f54a2f7d2e9c88b3" for nodes
2018-11-26T20:22:34Z [ℹ]  creating EKS cluster "dev303-workshop" in "us-west-2" region
2018-11-26T20:22:34Z [ℹ]  will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup
2018-11-26T20:22:34Z [ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-west-2 --name=dev303-workshop'
2018-11-26T20:22:34Z [ℹ]  creating cluster stack "eksctl-dev303-workshop-cluster"
2018-11-26T20:33:16Z [ℹ]  creating nodegroup stack "eksctl-dev303-workshop-nodegroup-0"
2018-11-26T20:36:47Z [✔]  all EKS cluster resource for "dev303-workshop" had been created
2018-11-26T20:36:47Z [✔]  saved kubeconfig as "/home/ec2-user/.kube/config"
2018-11-26T20:36:47Z [ℹ]  the cluster has 0 nodes
2018-11-26T20:36:47Z [ℹ]  waiting for at least 4 nodes to become ready
2018-11-26T20:37:18Z [ℹ]  the cluster has 4 nodes
2018-11-26T20:37:18Z [ℹ]  node "ip-192-168-39-212.us-west-2.compute.internal" is ready
2018-11-26T20:37:18Z [ℹ]  node "ip-192-168-40-114.us-west-2.compute.internal" is ready
2018-11-26T20:37:18Z [ℹ]  node "ip-192-168-9-131.us-west-2.compute.internal" is ready
2018-11-26T20:37:18Z [ℹ]  node "ip-192-168-94-204.us-west-2.compute.internal" is ready
2018-11-26T20:37:18Z [ℹ]  kubectl command should work with "/home/ec2-user/.kube/config", try 'kubectl get nodes'
2018-11-26T20:37:18Z [✔]  EKS cluster "dev303-workshop" in "us-west-2" region is ready

途中経過の様子。

EKS cluster "dev303-workshop" in "us-west-2" region is ready というログが出ていれば作成完了です。

2018-11-26T20:36:47Z [✔]  saved kubeconfig as "/home/ec2-user/.kube/config"

こちらのログを見るにkubernetesのConfigurationが作成されているようです。

nodesの数を確認します。これ以降は .kube/config 以下の設定を参照できるため、EKSというよりもkubernetesでの操作になります。

$ kubectl get nodes
NAME                                           STATUS    ROLES     AGE       VERSION
ip-192-168-39-212.us-west-2.compute.internal   Ready     <none>    1m        v1.10.3
ip-192-168-40-114.us-west-2.compute.internal   Ready     <none>    1m        v1.10.3
ip-192-168-9-131.us-west-2.compute.internal    Ready     <none>    1m        v1.10.3
ip-192-168-94-204.us-west-2.compute.internal   Ready     <none>    1m        v1.10.3

4つのノードが立ち上がっているのが確認できました。

CloudFormationで必要なRoleを作成する

ApplicationをDeployする前に必要なRoleを事前に作成しておきます。

aws cloudformation create-stack \
--stack-name dev303-workshop \
--template-url https://s3.amazonaws.com/aws-tracing-workshop-artifacts/cloudformation.yaml --capabilities CAPABILITY_NAMED_IAM

コンソールを確認しながらCFnの構築をじっと待ちます。完了したら以下のコマンドを実行。こちらはCloneしたRepository内で実行しましょう（/deploy が見えるトコロ）

$ kubectl create -f deploy/eks/prep.yaml
namespace "microservices-aws" created
configmap "services-environment-config" created
secret "microservices-aws" created

この後にDeployするためのCredentialを取得する以下のコマンドを実行したのですが、うまくいきませんでした。

# Get EKS worker node IAM instance role ARN
PROFILE=$(aws ec2 describe-instances --filters Name=tag:Name,Values=dev303-workshop-0-Node --query 'Reservations[0].Instances[0].IamInstanceProfile.Arn' --output text | cut -d '/' -f 2)

# Fetch IAM instance role name
ROLE=$(aws iam get-instance-profile --instance-profile-name $PROFILE --query "InstanceProfile.Roles[0].RoleName" --output text)

echo $ROLE # Print role name

# Attach IAM policy for Orderservice
ARN=$(aws iam list-policies --scope Local --query "Policies[?PolicyName=='OrderserviceSQS-Policy'].Arn" --output text)
echo $ARN
aws iam attach-role-policy --role-name $ROLE --policy-arn $ARN

# Attach IAM poliy for Catalogservice
ARN=$(aws iam list-policies --scope Local --query "Policies[?PolicyName=='CatalogserviceDDB-Policy'].Arn" --output text)
echo $ARN
aws iam attach-role-policy --role-name $ROLE --policy-arn $ARN

原因は PROFILE の取得がうまくいかず。 Reservations[0].Instances[0] までは情報が存在し、Jsonを見てみるとそのさらに先のProperty名で指定している IamInstanceProfile が見当たらないという。

ここで時間切れになりました。

Trouble shooting

EKS Clusterの立ち上げの段階ですでにいくつか躓いたので共有します。

Cloud9のセッションが切れてeksctlの処理が途中で止まる

会場のネットワークが不安定だったことがあり、途中でWiFiを自前のモバイルWiFiへ切り替えました。そのためCloud9のセッションが切れたと思われます。そのため、.kube/config が設定されずに新たに立ち上げたTerminalでは以下のようなログメッセージが出力されてしまい、会場にいたSAの方に助けてもらいました。

The connection to the server localhost:8080 was refused

恐らく .kube/config がリセットされてしまったためなので、以下のコマンドを叩くと再度configを作成してくれるようです。

$ eksctl utils write-kubeconfig --name=dev303-workshop --region=us-west-2
2018-11-26T13:39:50-08:00 [✔]  saved kubeconfig as "/home/ec2-user/.kube/config"

EKSの環境をDeleteしてもなにかのリソースが残る

EKSのClusterは一度作り直したのですが、CloudFormationを確認するとまだ CREATE_COMPLETED の状態になっている明らかにEKS ClusterのCFnスタックが残っていました。これが残っていると eksctl create でClusterの作成に失敗するため、手動でスタックの削除を実行する必要がありました。

またRoleの削除がうまくいかず、Rollbackするスタックもあったためこちらも手動で削除するなど、一度躓いてしまうと自前で関連リソースを探す必要があったため、再トライするのに時間がかかってしまいました。

予想を超える巨大インスタンスが立ち上がる

トラブルではないですが、ドキュメントに以下の記載があるようにとんでもない大きさのインスタンスが４台も立ち上がります。

This will create a cluster in the us-west-2 (Oregon) region with 4 x m5.large instances.

＿人人人人人人人人＿
＞　4 * m5.large　＜
￣Y^Y^Y^Y^Y^Y^Y￣

想像を超える巨大インスタンスに恐れおののきながら作業をすすめます（多分これがワークショップ用のテンポラリーアカウントが用意されなかった原因ではないかと思っています）

まとめ

EKSを本格的に触るとても良いきっかけになりました。良いところ、悪いところ含め色々と実感できたのは良かったです。SAの方に直接色々とサポートをしてもらうことができたため、動作の不明点や関連したリソースのスタックについてと言ったところを直接聞くことができたのも良かったかと思います。

残念だったのは会場のWiFiが不調で開始までに時間がかかってしまったこと、短い時間の中で行う作業がとても多かったため、理解するより先に手を動かさないと全く間に合わない状況になってしまったことです。

しかしながら、実際にMicroserviceを構築するために気をつけなければならないポイントや構築の準備で考慮すべき事項等を実感できるとても良い経験でした。